home *** CD-ROM | disk | FTP | other *** search
-
- TP/IX Working Group R. L. Ullmann
- Internet Draft Process Software Corporation
- June 30, 1993
-
-
-
-
-
-
- TCP version 7 options
-
- 1 Status of this Memo
-
- This memo describes experimental option definitions for use with the
- TP/IX version 7 TCP.
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. (Note that other groups may also distribute
- working documents as Internet Drafts).
-
- Internet Drafts are draft documents valid for a maximum of six months.
- Internet Drafts may be updated, replaced, or obsoleted by other
- documents at any time. It is not appropriate to use Internet Drafts
- as reference material or to cite them other than as a "working draft"
- or "work in progress."
-
- Please check the I-D abstract listing contained in each Internet Draft
- directory to learn the current status of this or any other Internet
- Draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Ullmann DRAFT: expires December 29, 1993 [page 1]
-
- Internet draft TCP version 7 options June 30, 1993
-
-
- 2 Contents
-
- 1 Status of this Memo . . . . . . . . . . . . . . . . 1
- 2 Contents . . . . . . . . . . . . . . . . . . . . . . 2
- 3 Introduction . . . . . . . . . . . . . . . . . . . . 3
- 4 Selective Acknowledgement . . . . . . . . . . . . . 3
- 5 Time Stamp . . . . . . . . . . . . . . . . . . . . . 3
- 6 Record Mark . . . . . . . . . . . . . . . . . . . . 4
- 7 References . . . . . . . . . . . . . . . . . . . . . 6
- 8 Author's Address . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Ullmann DRAFT: expires December 29, 1993 [page 2]
-
- Internet draft TCP version 7 options June 30, 1993
-
-
- 3 Introduction
-
- This memo presents several options for version 7 of the TCP. Two of
- them provide for the extensions defined by the TCP Large Windows
- project not covered in the basic field definitions. The other option
- helps provide some of the semantics expected of the transport layer by
- OSI applications, and may be useful to other applications defined on
- the TCP.
-
- 4 Selective Acknowledgement
-
- The selective acknowledgement (SACK) option (type = 4) indicates that
- some block of data, not "connected" to the left (start) edge of the
- TCP window has been received. It need not be transmitted again by the
- other TCP and will be acknowledged by the TCP sending the SACK option
- in the normal way when the window edge arrives at the first sequence
- number in the block.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | type = 4 | length = 16 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + start sequence number +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + end sequence number +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- This acknowledges receipt of bytes between (start) and (end-1). If
- end is equal to or less than start in sequence space, the option is
- meaningless, and must be ignored.
-
- The SACK option should not be used to acknowledge the FIN (or SYN)
- sequence number. A selective acknowledgement that attempts to
- acknowledge the FIN sequence number should be ignored.
-
- The selective acknowledgement option may occur more than once in a TCP
- segment, acknowledging receipt of more than one block of data. A
- block may represent more than one consecutive segment. It is probably
- unreasonable to expect the other TCP to use a SACK that acknowledges
- less than a full segment.
-
- 5 Time Stamp
-
- The time stamp option (type = 5) is used for enhanced measurement of
- the round-trip delays of the network path being used for a TCP
- connection. It contains a timestamp value selected by the sending
- TCP, and a copy of the (usually) most recently-received timestamp from
- the other TCP.
-
-
-
-
- Ullmann DRAFT: expires December 29, 1993 [page 3]
-
- Internet draft TCP version 7 options June 30, 1993
-
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | type = 5 | length = 16 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + Timestamp value +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + Echoed timestamp reply +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- The timestamp field is only valid when its value is non-zero.
-
- The reply field is only valid when the ACK flag is set in the TCP
- header, and the value of the reply field is non-zero. When the ACK
- flag is not set, the timestamp reply field (if the option appears)
- must be zero.
-
- Please refer to [RFC1323] for the precise use of this option in
- round-trip measurements. The version 7 TS option is not used for the
- PAWS mechanism described therein; the 64-bit sequence space is not
- expected to wrap within a connection.
-
- The exact semantics of the timestamp values used by the (remote) TCP
- are not specified; the frequency, resolution, and stabilty of the
- remote clock are not used by the local TCP. The local TCP should only
- copy specific remote TS values into the echo-reply field. ([RFC1323]
- specifies that the TS values must be monotonically non-decreasing, for
- use with PAWS; this may be unnecessary here.)
-
- 6 Record Mark
-
- The record mark option (type = 6) indicates the boundary of an
- application record. The record mark is constructed by the TCP service
- interface at the sender, and passed to the receiver's service
- interface. It is not used directly by the TCP, except that the TCP
- may use record marks as hints to where segments might be divided for
- maximum performance.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | type = 6 | length = 8 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + mark sequence number +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
- Ullmann DRAFT: expires December 29, 1993 [page 4]
-
- Internet draft TCP version 7 options June 30, 1993
-
-
-
-
- The mark sequence number identifies the first octet of the following
- record. This is consistant with the definition of the acknowlegement
- field, which identifies a point "in between" octets by specifying the
- number of the following octet.
-
- The mark must point somewhere within the segment carrying the option,
- i.e. it must be between the segment sequence number and the sequence
- number plus the segment size, inclusive. Receivers may ignore record
- mark options that point outside the segment.
-
- The option may occur any number of times within one segment.
-
- There is an implicit record mark at sequence SYN+1, and an implicit
- mark at sequence FIN. (And remember that these may be the same
- point.) A sending TCP may prefer to send an explicit mark at SYN+1,
- possibly on the SYN segment itself; this allows early indication to
- the receiver's application that record marking is available and will
- be used.
-
- Note that to be useful when a record is sent in exactly one segment,
- the option marking the record boundary should point at the end of the
- segment. (I.e. the record mark between two records should be sent
- with the first record, not the second.) If this is not done, the
- reciever would have to wait for a subsequent record before being able
- to pass the first to the application.
-
- There are no zero-length records. The record mark itself does not
- have a sequence number; there is no way to distinguish a repeat of a
- record mark (in, for example, a segment containing retransmitted data)
- and thus no way to deliver two or more record marks at the same
- sequence number.
-
- Finally, it may be desireable for the TCP to request network layer
- conversion prohibition (IP Don't Convert option) to prevent loss of
- record marking if the network route changes to traverse version 4
- systems. (Another possibility is to redefine the high bit of the
- option type field to be an indicator that the conversion must fail if
- the option is not translatable; this feature was in a prior version of
- TP/IX. If such a failure occured, the datagram would be returned with
- ICMP conversion failed/code 11.)
-
- An earlier version of TP/IX specified a TCP flag (M), indicating "more
- data" in the style of (e.g.) X.25. When the M flag was clear, the
- segment was the last (or only) part of the application record; when
- set, it indicated that there was more data to come. The flag method
- was discarded in favor of the option because it added constraints to
- the TCP that are undesirable. Like X.25 and OSI TP0, the flag permits
- a TSDU (Transport Service Data Unit) to span multiple TPDUs, but does
- not permit the coelescing of multiple small TSDUs into one TPDU, and
- thence one network datagram. In the TCP architecture, segmentation is
- entirely in the control of the TCP, and the record marking is only of
- interest to the application.
-
-
-
-
-
- Ullmann DRAFT: expires December 29, 1993 [page 5]
-
- Internet draft TCP version 7 options June 30, 1993
-
-
- 7 References
-
- [RFC1323] V. Jacobson, R. T. Braden, D. A. Borman. TCP extensions
- for high performance. May, 1992.
-
- [RFC1475] Robert Ullmann. TP/IX: The Next Internet. Process
- Software Corporation. June, 1993.
-
- [RFC1476] Robert Ullmann. RAP: Internet Route Access Protocol.
- Process Software Corporation. June, 1993.
-
- 8 Author's Address
-
-
- Robert Ullmann
- Process Software Corporation
- 959 Concord Street
- Framingham, MA 01701
- USA
-
- Phone: +1 508 879 6994 x226
- Email: Ariel@Process.COM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Ullmann DRAFT: expires December 29, 1993 [page 6]
-